Location-Based Management of Virtual Machines in Datacenters

ABSTRACT

Embodiments manage physical locations of virtual machines (VMs) in a datacenter. A computing device, such as a cloud management device, aggregates location information for the VMs executing on hosts. The computing device compares the aggregated location information with event data to identify VMs potentially affected by adverse events (e.g., severe weather, scheduled maintenance, natural disasters, etc.). The computing device initiates migration of the affected VMs from their hosts to unaffected hosts. In some embodiments, the location information includes global positioning system (GPS) coordinates obtained by the hosts and shared with the computing device.

BACKGROUND

Cloud-based datacenters have thousands of virtual machines (VMs)executing on hosts. The hosts reside in racks within the datacenters.The large size of the datacenters adds to the difficulty of locatinghardware within the datacenters. Some existing systems use globalpositioning systems (GPS) to locate the physical position of the rackswithin the datacenters for maintenance and upgrades. Other existingsystems use radio frequency identification (RFID) and long-rangenavigation (LORAN). Even with the knowledge of the physical racklocations, however, the existing systems lack a mechanism fordetermining the physical location of each VM executing on the hosts inthe datacenter.

Further complicating this effort, VMs often move from host to host, andfrom datacenter to datacenter. VMs are migrated as their resource needschange, as the available resources within the datacenters change, forload-balancing purposes, for backup and restore operations, and thelike. For example, thousands of VMs may be in the process of migrationat any one point in time. Tracking the location of the VMs during theseconcurrent migrations is difficult.

In some existing systems, an administrator manually identifies thetarget hosts to receive the VMs to be moved. These existing systems lackan automated mechanism for determining where to locate each VM to bemoved within the datacenters, and the conditions under which to move theVMs.

SUMMARY

One or more embodiments described herein relocate virtual machines (VMs)in anticipation of adverse events. A computing device, such as a cloudmanagement device, aggregates location information for the VMs from oneor more hosts executing the VMs in a virtualized datacenter. Thecomputing device compares the aggregated location information with eventdata describing the potentially adverse events to identify affected VMs.The computing device migrates one or more of the affected VMs, inanticipation of the adverse events, to hosts not affected by the adverseevents.

To facilitate aggregation of the location information, embodimentsdescribed herein contemplate the inclusion of positioning systems invirtualized datacenters. The positioning systems, such as globalpositioning systems, enable each host to determine and transmit thelocation information for the VMs executing on the host to the computingdevice.

This summary introduces a selection of concepts that are described inmore detail below. This summary is not intended to identify essentialfeatures, nor to limit in any way the scope of the claimed subjectmatter.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram of an exemplary host computing device.

FIG. 2 is a block diagram of virtual machines that are instantiated on acomputing device, such as the host computing device shown in FIG. 1.

FIG. 3 is a block diagram of an exemplary computing device proactivelymanaging migration of virtual machines in datacenters.

FIG. 4 is a flowchart of an exemplary method performed by a computingdevice to select and migrate virtual machines in anticipation of adverseevents affecting the virtual machines.

FIG. 5 is a block diagram of an example migration from one virtualizeddatacenter to another virtualized datacenter.

FIG. 6 is a block diagram of an exemplary implementation of a proactivevirtual machine migration management system that is responsive to eventdata.

FIG. 7A and FIG. 7B are block diagrams of an example virtual machinemigration from one rack to another rack in a virtualized datacenter.

FIG. 8A is a block diagram of an example migration of a virtual machinefrom a first host to a second host, where the first host and the secondhost share storage.

FIG. 8B is a block diagram of an example migration of a virtual machinefrom a first host to a second host, where the first host and the secondhost do not share storage.

FIG. 9 is a block diagram of an example virtual machine whose resourcesspan multiple racks in a virtualized datacenter.

Corresponding reference characters indicate corresponding partsthroughout the drawings.

DETAILED DESCRIPTION

Embodiments described herein maintain an inventory of virtual machines(VMs) and corresponding location information. Location informationdescribes, among other data, a physical location of resources (e.g.,processing, storage, memory, power, etc.) associated with VMs. In someembodiments, a cloud management device leverages location information torelocate one or more of VMs in anticipation of future, potentiallyadverse events. In such embodiments, cloud management device receivesevent data describing the potentially adverse events, and compares theevent data with location information to identify and move affected VMs.In this manner, cloud management device protects the affected VMs andprevents downtime, loss of data, and the like.

By reporting location information, such as global positioning system(GPS) coordinates, to a computing device such as cloud managementdevice, aspects of the disclosure enable creation of an inventory of VMsand corresponding location information in a virtualized datacenter. Bycombining a logical inventory of VMs (e.g., which VM is executed bywhich host) and a physical inventory (e.g., a physical location of hostexecuting VM), cloud management device is able to blunt or otherwisemitigate the effects of adverse events, make a more informed selectionof target hosts to receive affected VMs, and improve efficiency. In someembodiments, location information represents a topology of thevirtualized datacenter.

Embodiments of the disclosure enable locating VMs moved to anotherdatacenter prior to a disaster, move VMs closer to newer storage racksfor improved performance, move VMs away from a section of the datacenterabout to undergo maintenance or improvement, and more.

FIG. 1 is a block diagram of an exemplary host computing device 100,also referred to as host 100. Host computing device 100 includes aprocessor 102 for executing instructions. In some embodiments,executable instructions are stored in a memory 104. Memory 104 is anydevice allowing information, such as executable instructions and/orother data, to be stored and retrieved. For example, memory 104 mayinclude one or more random access memory (RAM) modules, flash memorymodules, hard disks, solid state disks, and/or optical disks. In anotherexample, hard disks and/or optical disks are located in a datastore(e.g., locally or remotely attached).

Host computing device 100 may include a user interface device 110 forreceiving data from a user 108 and/or for presenting data to user 108.User 108 may interact indirectly with host computing device 100 viaanother computing device such as VMware's vCenter Server or othermanagement device. User interface device 110 may include, for example, akeyboard, a pointing device, a mouse, a stylus, a touch sensitive panel(e.g., a touch pad or a touch screen), a gyroscope, an accelerometer, aposition detector, and/or an audio input device. In some embodiments,user interface device 110 operates to receive data from user 108, whileanother device (e.g., a presentation device) operates to present data touser 108. In other embodiments, user interface device 110 has a singlecomponent, such as a touch screen, that functions to both output data touser 108 and receive data from user 108. In such embodiments, userinterface device 110 operates as a presentation device for presentinginformation to user 108. In such embodiments, user interface device 110represents any component capable of conveying information to user 108.For example, user interface device 110 may include, without limitation,a display device (e.g., a liquid crystal display (LCD), organic lightemitting diode (OLED) display, or “electronic ink” display) and/or anaudio output device (e.g., a speaker or headphones). In someembodiments, user interface device 110 includes an output adapter, suchas a video adapter and/or an audio adapter. An output adapter isoperatively coupled to processor 102 and configured to be operativelycoupled to an output device, such as a display device or an audio outputdevice.

Host computing device 100 also includes a network communicationinterface 112, which enables host computing device 100 to communicatewith a remote device (e.g., another computing device) via acommunication medium, such as a wired or wireless packet network. Forexample, host computing device 100 may transmit and/or receive data vianetwork communication interface 112. User interface device 110 and/ornetwork communication interface 112 may be referred to collectively asan input interface and may be configured to receive information fromuser 108.

Host computing device 100 further includes a storage interface 116 thatenables host computing device 100 to communicate with one or moredatastores, which store virtual disk images, software applications,and/or any other data suitable for use with the methods describedherein. In exemplary embodiments, storage interface 116 couples hostcomputing device 100 to a storage area network (SAN) (e.g., a FibreChannel network) and/or to a network-attached storage (NAS) system(e.g., via a packet network). The storage interface 116 may beintegrated with network communication interface 112.

FIG. 2 depicts a block diagram of virtual machines 235 ₁, 235 ₂ . . .235 _(N) that are instantiated on host computing device 100. Hostcomputing device 100 includes a hardware platform 205, such as an x86architecture platform. Hardware platform 205 may include processor 102,memory 104, network communication interface 112, user interface device110, and other input/output (I/O) devices, such as a presentation device106 (shown in FIG. 1). A virtualization software layer, also referred tohereinafter as a hypervisor 210, is installed on top of hardwareplatform 205.

The virtualization software layer supports a virtual machine executionspace 230 within which multiple virtual machines (VMs 235 ₁-235 _(N))may be concurrently instantiated and executed. Hypervisor 210 includes adevice driver layer 215, and maps physical resources of hardwareplatform 205 (e.g., processor 102, memory 104, network communicationinterface 112, and/or user interface device 110) to “virtual” resourcesof each of VMs 235 ₁-235 _(N) such that each of VMs 235 ₁-235 _(N) hasits own virtual hardware platform (e.g., a corresponding one of virtualhardware platforms 240 ₁-240 _(N)), each virtual hardware platformhaving its own emulated hardware (such as a processor 245, a memory 250,a network communication interface 255, a user interface device 260 andother emulated I/O devices in VM 235 ₁). Hypervisor 210 may manage(e.g., monitor, initiate, and/or terminate) execution of VMs 235 ₁-235_(N) according to policies associated with hypervisor 210, such as apolicy specifying that VMs 235 ₁-235 _(N) are to be automaticallyrestarted upon unexpected termination and/or upon initialization ofhypervisor 210. In addition, or alternatively, hypervisor 210 may manageexecution VMs 235 ₁-235 _(N) based on requests received from a deviceother than host computing device 100. For example, hypervisor 210 mayreceive an execution instruction specifying the initiation of executionof first VM 235 ₁ from a management device via network communicationinterface 112 and execute the execution instruction to initiateexecution of first VM 235 ₁.

In some embodiments, memory 250 in first virtual hardware platform 240 ₁includes a virtual disk that is associated with or “mapped to” one ormore virtual disk images stored on a disk (e.g., a hard disk or solidstate disk) of host computing device 100. The virtual disk imagerepresents a file system (e.g., a hierarchy of directories and files)used by first VM 235 ₁ in a single file or in a plurality of files, eachof which includes a portion of the file system. In addition, oralternatively, virtual disk images may be stored on one or more remotecomputing devices, such as in a storage area network (SAN)configuration. In such embodiments, any quantity of virtual disk imagesmay be stored by the remote computing devices.

Device driver layer 215 includes, for example, a communication interfacedriver 220 that interacts with network communication interface 112 toreceive and transmit data from, for example, a local area network (LAN)connected to host computing device 100. Communication interface driver220 also includes a virtual bridge 225 that simulates the broadcastingof data packets in a physical network received from one communicationinterface (e.g., network communication interface 112) to othercommunication interfaces (e.g., the virtual communication interfaces ofVMs 235 ₁-235 _(N)). Each virtual communication interface for each VM235 ₁-235 _(N), such as network communication interface 255 for first VM235 ₁, may be assigned a unique virtual Media Access Control (MAC)address that enables virtual bridge 225 to simulate the forwarding ofincoming data packets from network communication interface 112. In anembodiment, network communication interface 112 is an Ethernet adapterthat is configured in “promiscuous mode” such that all Ethernet packetsthat it receives (rather than just Ethernet packets addressed to its ownphysical MAC address) are passed to virtual bridge 225, which, in turn,is able to further forward the Ethernet packets to VMs 235 ₁-235 _(N).This configuration enables an Ethernet packet that has a virtual MACaddress as its destination address to properly reach the VM in hostcomputing device 100 with a virtual communication interface thatcorresponds to such virtual MAC address.

Virtual hardware platform 240 ₁ may function as an equivalent of astandard x86 hardware architecture such that any x86-compatible desktopoperating system (e.g., Microsoft WINDOWS brand operating system, LINUXbrand operating system, SOLARIS brand operating system, NETWARE, orFREEBSD) may be installed as guest operating system (OS) 265 in order toexecute applications 270 for an instantiated VM, such as first VM 235 ₁.Virtual hardware platforms 240 ₁-240 _(N) may be considered to be partof virtual machine monitors (VMM) 275 ₁-275 _(N) that implement virtualsystem support to coordinate operations between hypervisor 210 andcorresponding VMs 235 ₁-235 _(N). Those with ordinary skill in the artwill recognize that the various terms, layers, and categorizations usedto describe the virtualization components in FIG. 2 may be referred todifferently without departing from their functionality or the spirit orscope of the disclosure. For example, virtual hardware platforms 240₁-240 _(N) may also be considered to be separate from VMMs 275 ₁-275_(N), and VMMs 275 ₁-275 _(N) may be considered to be separate fromhypervisor 210. One example of hypervisor 210 that may be used in anembodiment of the disclosure is included as a component in VMware's ESXbrand software, which is commercially available from VMware, Inc.

FIG. 3 is a block diagram of an exemplary computing device 302proactively managing migration of VMs 235 in one or more virtualizeddatacenters 316. An administrator, or other user 108, interacts withcomputing device 302. Computing device 302 represents any deviceexecuting instructions (e.g., as application programs, operating systemfunctionality, or both) to implement the operations and functionalityassociated with computing device 302. For example, computing device 302executes instructions to relocate VMs 235 in anticipation of adverseevents. Computing device 302 may include any computing device orprocessing unit. For example, computing device 302 may represent a groupof processing units or other computing devices, such as in a cloudcomputing configuration. In such an example, computing device 302 may beassociated with a particular virtualized datacenter 316.

Computing device 302 has at least one processor 304 and a memory area306. Processor 304 includes any quantity of processing units, and isprogrammed to execute computer-executable instructions for implementingaspects of the disclosure. The instructions may be performed byprocessor 304 or by multiple processors executing within computingdevice 302, or performed by a processor external to computing device302. In some embodiments, processor 304 is programmed to executeinstructions such as those illustrated in the figures to protect VMs 235in anticipation of adverse events affecting virtualized datacenter 316.

Memory area 306 includes any quantity of computer-readable mediaassociated with or accessible by computing device 302. Memory area 306,or portions thereof, may be internal to computing device 302, externalto computing device 302, or both.

In the example of FIG. 3, memory area 306 further stores an inventory308 of VMs 235 in one or more of virtualized datacenters 316. Inventory308 may be represented as data identifying hosts 100 associated withvirtualized datacenter 316 and VMs 235 registered or otherwiseassociated with each of hosts 100. Inventory 308 may be stored asrecords in a database, fields in a flat file, elements in one or moresets, and/or via other data management means.

Memory area 306 further stores location information 310 describingphysical locations of VM 235 in virtualized datacenter 316, aggregatedfrom hosts 100. Event data 312 is received by computing device 302 andstored in memory area 306. Location information 310 and event data 312are described further with reference to FIG. 4.

Computing device 302 communicates with one or more of virtualizeddatacenters 316 by, for example, one or more networks 314. Networks 314include any means for communication between computing device 302 andvirtualized datacenter 316, such as intranets, internets, local areanetworks, wide area networks, and the like. Further, each network 314may be implemented as a wired network, a wireless network, and/or a bus(e.g., as a system on a chip). However, aspects of the disclosure areoperable with any network type or configuration.

Virtualized datacenter 316 includes a plurality of physical racks 318,such as rack #1 through rack # N. In some embodiments, each rack 318 hasstorage 320, and one or more hosts 100 such as host #1 through host # M.Each of hosts 100 executes at least one VM 235. Each rack 318 furtherhas at least one positioning system 322 associated therewith.Positioning systems 322 generally include two-dimensional positioningsystems, three-dimensional positioning systems, satellite-basedpositioning systems, radio frequency-based positioning systems, and thelike. An example satellite-based positioning system includes a GPS.Examples of a radio frequency-based positioning system include a radiofrequency identification (RFID), BLUETOOTH brand communication, whitespace systems, and the like. Each of positioning systems 322 may includea transmitter and, in some embodiments, a receiver. Positioning system322 may be located on racks 318, motherboards, or otherwise co-locatedwith one or more hosts 100.

In some embodiments, computing device 302 is located separate fromvirtualized datacenter 316, as shown in FIG. 3. In other embodiments,computing device 302 is located with virtualized datacenter 316, or inanother virtualized datacenter 316.

FIG. 4 is a flowchart of an exemplary method performed by computingdevice 302 to select and migrate virtual machines in anticipation ofadverse events affecting the virtual machines. While method 400 isdescribed with reference to execution by computing device 302 (shown inFIG. 3), it is contemplated that method 400 may be performed by anycomputing device. For example, method 400 may be performed by acomputing device (e.g., one of hosts 100) not affected by a potentiallyadverse event, as defined by event data 312. For example, method 400 isperformed by a computing device located remote from virtualizeddatacenter 316. Further, in some embodiments, the operations illustratedin FIG. 4 may be stored as computer-executable instructions on one ormore computer-readable media. The instructions may be kernel-levelinstructions.

Hosts 100 in virtualized datacenter 316 execute a driver, plug-in, orother instructions to obtain location information 310 (e.g., GPS data)for themselves from co-located GPS devices. Each host 100 that hasobtained location information 310 about itself exports locationinformation 310 along with information describing a set of VMs 235executing on that host 100 to computing device 302. Location information310 may also describe one or more error conditions, such as whether aGPS signal has been lost. The information describing the set of VMs 235may include executing VMs 235, powered-down VMs 235, performance of VMs235, and/or other information.

At 402, computing device 302 aggregates location information 310 for aplurality of VMs 235 executing on one or more hosts 100 in virtualizeddatacenter 316. Aggregating includes, but is not limited to, receivinglocation information 310 describing a location or position of VMs 235.For example, computing device 302 may receive (e.g., intermittently,periodically, regularly, etc.) location information 310 from each ofhosts 100 (e.g., from hypervisor 210 executing on each host 100). Inanother example, computing device 302 fetches, or otherwise requests,location information 310 from each of hosts 100.

In some embodiments, computing device 302 maintains, and/or accesses,inventory 308 of VMs 235 in one or more virtualized datacenters 316. Inone example, computing device 302 aggregates location information 310for each of VMs 235 in inventory 308. In another example, computingdevice 302 aggregates location information 310 for a subset of VMs 235in inventory 308. In this manner, computing device 302 selectivelyaggregates location information 310 (e.g., aggregate only for those VMs235 in inventory 308, or only for a subset of VMs 235 in inventory 308).

For each VM 235, location information 310 includes an identifier of VM235 and data describing a location of VM 235. Data describing a locationof VM 235 may include, for example: GPS coordinates of host 100, a nameof host 100 executing VM 235, an identifier of rack 318 containing host100 executing VM 235, and/or an address of virtualized datacenter 316.As such, aggregating location information 310 may include aggregatingdata describing a location of hosts 100 executing VMs 235.

In some embodiments, each of hosts 100 has access to GPS data describinga location of host 100. For example, each of hosts 100 may have, orcommunicate with, a GPS transmitter co-located with host 100. In anotherexample, multiple hosts 100 may share a common, co-located GPStransmitter (e.g., multiple hosts 100 in the same rack 318, array, room,building, etc.). In such embodiments, VMs 235 themselves do not haveaccess to, nor are aware of, the GPS transmitter.

At 404, computing device 302 obtains or otherwise receives event data312. For example, computing device 302 may poll, request, subscribe,and/or fetch event data 312 from one or more content sources. As anotherexample, computing device 302 receives event data 312 (e.g.,periodically, intermittently, regularly, etc.). Content sources include,but are not limited to, data stores, web services, and/or othercomputing devices storing event data 312. Exemplary event data 312includes, but is not limited to, weather forecasts, weather alerts,seismic information, maintenance events (e.g., scheduled maintenanceevents), test events, alerts regarding natural disasters, and/or alertsregarding other disasters (e.g., crime, terrorism, etc.). As such,computing device 302 may obtain event data 312 from weather services,calendar services, and the like.

In some embodiments, computing device 302 selectively obtains event data312. For example, computing device 302 requests and receives event data312 associated with locations described by the aggregated locationinformation 310. In this manner, computing device 302 obtains event data312 relating only to the locations of interest to computing device 302(e.g., those locations at which VMs 235 are executing).

At 406, computing device 302 compares the aggregated locationinformation 310 with the received event data 312 to identify affectedVMs 235. In some embodiments, computing device 302 determines whetherany of the locations of VMs 235 in virtualized datacenter 316 may beaffected by an adverse event represented by event data 312. For example,if event data 312 indicates that a strong storm is heading towards aparticular virtualized datacenter 316, computing device 302 may identifythose VMs 235 (via location information 310) executing on hosts 100 thatare physically resident in the particular virtualized datacenter 316. Inan example in which location information 310 describes the locations ofhosts 100, computing device 302 compares location information 310 withthe received event data 312 to identify affected hosts 100, and thencompares the affected hosts 100 with inventory 308 of VMs 235 toidentify the affected VMs 235.

In another example, if event data 312 indicates that maintenance isscheduled for a particular rack 318 in virtualized datacenter 316,computing device 302 identifies those VMs 235 (via location information310) executed by hosts 100 physically residing in the particular rack318.

If computing device 302 identifies any affected VMs 235 at 408,computing device 302 migrates the affected VMs 235 at 410 from theirhosts 100 (affected by event data 312) to other hosts 100 (not affectedby event data 312). In some embodiments, migrating the affected VMs 235including notifying the other hosts 100 at 412 of the impendingmigration, and then receiving updated location information 310 at 414from the other hosts 100 after the migration. The updated locationinformation 310 describes the new locations of the migrated VMs 235. Inthis manner, computing device 302 confirms that the affected VMs 235migrated successfully.

Computing device 302 selects the other hosts 100 based on event data 312to ensure that the other hosts 100 are not affected by event data 312.For example, computing device 302 selects hosts 100 that are outside theforecasted path of a storm, and/or in one of racks 318 that are notscheduled for maintenance, etc.

In some embodiments, event data 312 has a time value associatedtherewith. The time value may indicate a period during which event data312 is valid, and/or a point after which event data 312 is no longervalid (e.g., stale). After event data 312 becomes invalid or stale,computing device 302 may move the migrated VMs 235 back to theiroriginal hosts 100.

Alternatively or in addition to migrating the affected VMs 235,computing device 302 may power down the affected VMs 235 to protect theaffected VMs 235 from any adverse event indicated by event data 312.

FIG. 5 is a block diagram of a migration of VM 235 from one virtualizeddatacenter 316 to another virtualized datacenter 316. For example, FIG.5 illustrates performance of the operations illustrated and described inFIG. 4. Two satellites 502 capable of relaying GPS data are shown inFIG. 5, although those skilled in the art will note that any quantity ofsatellites 502 may be employed. Further, aspects of the disclosure areoperable with positioning systems 322 other than GPS.

In operation, computing device 302 aggregates, from a plurality of hosts100 in a first virtualized datacenter 504, location information 310 fora plurality of VMs 235 executing in first virtualized datacenter 504. Inresponse to receipt of event data 312 describing a future adverse event,computing device 302 compares the aggregated location information 310with the received event data 312 to identify at least one affected VM235. Computing device 302 migrates the affected VM 235 from a host infirst virtualized datacenter 504 to a host in a second virtualizeddatacenter 506. Migrating includes, but is not limited to, performingone or more of the following operations in anticipation of the futureadverse event: moving, replicating, cloning, powering down, and/orpowering up. In some embodiments, migrating is performed by operationssuch as vMotion and/or svMotion from VMware, Inc.

FIG. 6 is a block diagram of an exemplary implementation of a proactivevirtual machine migration management system that is responsive to eventdata 312. The exemplary implementation of FIG. 6 includes cloudmanagement software (e.g., VMware's vCenter) executing on a cloudmanagement device 602 (e.g., computing device 302). Cloud managementdevice 602 receives input including event data 312, such as a weatherforecast or other pending disaster information, and location information310 describing VMs 235, such as GPS data describing a location of VMs235. Cloud management device 602 may also receive location information310 from hosts 100, such as Host A and/or Host B, and/or other cloudmanagement devices in other virtualized datacenters. Cloud managementdevice 602 determines the timeline (e.g., when to migrate) based on, forexample, the urgency of moving VMs 235 (and possibly moving them backafter the event). The urgency may be based on a time value associatedwith event data 312 (e.g., countdown time to realizing an effect of apotentially adverse event).

Cloud management device 602 may also determine a priority of migration(e.g., which VMs 235 to migrate first). Prioritizing may occur, forexample, based on service level agreements between virtualizeddatacenter 316 and its customers, types and functions of VMs 235, andthe like. For example, VMs 235 supporting an emergency 911 serviceshould be moved immediately and powered-on quickly, whereas other VMs235 may be moved gradually and can tolerate some data loss during thetransition. As a result, some VMs 235 are ranked higher than other VMs235. VMs 235 are then migrated based on the ranking. That, the higherranked, or prioritized, VMs 235 are migrated first by computing device302, followed by the lower-ranked VMs 235.

Cloud management device 602 communicates with multiple hosts 100, suchas Host A and Host B. Cloud management device 602 performs operations,such as those illustrated in FIG. 4, using the input event data 312 andinput location information 310 to identify and migrate affected VMs 235from one host 100 to another (e.g., Host A to Host B).

FIG. 7A and FIG. 7B are block diagrams of an example VM migration fromone rack 318 to another rack 318 in virtualized datacenter 316. Each ofracks 318 has a GPS transmitter sending location information 310 to oneor more of satellites 502. In the scenario illustrated in FIG. 7A, oneof racks 318 (e.g., rack 318 i) is scheduled to undergo maintenanceduring which VMs 235 executing in rack 318 ₁ will be powered down,offline, or otherwise unavailable. However, the other racks 318 willremain active. As shown in FIG. 7B, in anticipation of the scheduledmaintenance, computing device 302 identifies VMs (e.g., VM 1, VM 2, andVM 3) executing in the affected rack 318 ₁ that should be moved beforethe scheduled maintenance. For example, these three VMs may beidentified as critical, high priority, or otherwise not toleratingdisruption of execution (e.g., based on service level agreements).Computing device 302 migrates the three VMs to other racks 318 in thesame datacenter 316 in advance of the scheduled maintenance. Themigration may include the migration of storage 320 associated with eachof the three VMs.

In general, computing device 302 identifies a source host 802 (e.g.,determined to be likely affected by a future adverse event) and a targethost 804 (e.g., determined to be likely unaffected by the future adverseevent). Source host 802 and target host 804 may have shared storage 806,or other common storage. For example, FIG. 8A is a block diagram of anexample migration of VM 235 from source host 802 (e.g., a first host) totarget host 804 (e.g., a second host), where source host 802 and targethost 804 access shared storage 806. In this example, the portion ofstorage 806 associated with VM 235 does not have to be migrated (e.g.,the VM disk, memory, etc.) as both source host 802 and target host 804have access to the same shared storage 806. As such, migration routinessuch as vMotion by VMware, Inc. may be employed.

In contrast, FIG. 8B is a block diagram of an example migration of VM235 from source host 802 to target host 804, where source host 802 andtarget host 804 do not share storage. In this example, source storage808 associated with VM 235 on source host 802 is also migrated, moved,copied, replicated, etc. with target storage 810 on target host 804 aspart of the migration of VM 235 from source host 802 to target host 804.For example, a migration routine such as storage vMotion (e.g.,svMotion) by VMware, Inc. may be employed.

While some embodiments have been described herein with reference to VMs235 being contained in a single rack 318, some embodiments contemplateVMs 235 that span multiple racks 318. For example, FIG. 9 is a blockdiagram of an example VM 235 whose resources span multiple racks 318 invirtualized datacenter 316. The resources are referred to asdisaggregated, in such examples. The resource include, but are notlimited to, processing resources (e.g., central processing unit),working memory, persistent storage, and/or power. In this example, asingle VM 235 has its processor in one rack 318 ₂, working memory inanother rack 318 ₃, persistent storage in still another rack 318 ₄, andpower in yet another rack 318 ₅. A software interface from the GPStransmitter on physical storage to host 100 may be used to enablecomputing device 302 to know which resources of which VMs 235 are onwhich rack 318 (e.g., physical storage).

In some embodiments, only a subset of racks 318 may be affected by eventdata 312. Computing device 302 then moves only the resources in theaffected racks 318. For example, if only rack 318 ₃ is affected by apotential, future adverse event, then computing device 302 moves onlythe memory associated with VM 235 (e.g., to another of racks 318).

Additional Examples

The following scenarios are merely exemplary and not intended to belimiting in any way.

In one example, aspects of the disclosure are operable with hybrid cloudservices. In such an example, inventory 308 of VMs 235 are divided intoa plurality of cloud zones, with each of the cloud zones executing oneor more VMs 235. Upon determining that an adverse event may affect VMs235 in one of the cloud zones, computing device 302 migrates one or more(e.g., all) VMs 235 from the affected cloud zone (e.g., a first one ofthe cloud zones) to another cloud zone (e.g., a second one of the cloudzones).

In another example, rather than detecting a future adverse event,aspects of the disclosure react to occurrence of the adverse event. Insuch an example, when connectivity to an affected host 100 is lost,computing device 302 applies one or more default rules to migrate theaffected VMs 235 away from the affected host 100, and then verify via apositioning system 322 (e.g., GPS) that the affected VMs 235 have beenmoved away from the adverse event.

Exemplary Operating Environment

The operations described herein may be performed by a computer orcomputing device. The computing devices communicate with each otherthrough an exchange of messages and/or stored data. Communication mayoccur using any protocol or mechanism over any wired or wirelessconnection. A computing device may transmit a message as a broadcastmessage (e.g., to an entire network and/or data bus), a multicastmessage (e.g., addressed to a plurality of other computing devices),and/or as a plurality of unicast messages, each of which is addressed toan individual computing device. Further, in some embodiments, messagesare transmitted using a network protocol that does not guaranteedelivery, such as User Datagram Protocol (UDP). Accordingly, whentransmitting a message, a computing device may transmit multiple copiesof the message, enabling the computing device to reduce the risk ofnon-delivery.

By way of example and not limitation, computer readable media comprisecomputer storage media and communication media. Computer storage mediainclude volatile and nonvolatile, removable and non-removable mediaimplemented in any method or technology for storage of information suchas computer readable instructions, data structures, program modules orother data. Computer storage media are tangible, non-transitory, and aremutually exclusive to communication media. In some embodiments, computerstorage media are implemented in hardware. Exemplary computer storagemedia include hard disks, flash memory drives, digital versatile discs(DVDs), compact discs (CDs), floppy disks, tape cassettes, and othersolid-state memory. In contrast, communication media typically embodycomputer readable instructions, data structures, program modules, orother data in a modulated data signal such as a carrier wave or othertransport mechanism, and include any information delivery media.

Although described in connection with an exemplary computing systemenvironment, embodiments of the disclosure are operative with numerousother general purpose or special purpose computing system environmentsor configurations. Examples of well-known computing systems,environments, and/or configurations that may be suitable for use withaspects of the disclosure include, but are not limited to, mobilecomputing devices, personal computers, server computers, hand-held orlaptop devices, multiprocessor systems, gaming consoles,microprocessor-based systems, set top boxes, programmable consumerelectronics, mobile telephones, network PCs, minicomputers, mainframecomputers, distributed computing environments that include any of theabove systems or devices, and the like.

Embodiments of the disclosure may be described in the general context ofcomputer-executable instructions, such as program modules, executed byone or more computers or other devices. The computer-executableinstructions may be organized into one or more computer-executablecomponents or modules. Generally, program modules include, but are notlimited to, routines, programs, objects, components, and data structuresthat perform particular tasks or implement particular abstract datatypes. Aspects of the disclosure may be implemented with any number andorganization of such components or modules. For example, aspects of thedisclosure are not limited to the specific computer-executableinstructions or the specific components or modules illustrated in thefigures and described herein. Other embodiments of the disclosure mayinclude different computer-executable instructions or components havingmore or less functionality than illustrated and described herein.

Aspects of the disclosure transform a general-purpose computer into aspecial-purpose computing device when programmed to execute theinstructions described herein.

The embodiments illustrated and described herein as well as embodimentsnot specifically described herein but within the scope of aspects of theinvention constitute exemplary means for relocating VMs 235 inanticipation of adverse events. For example, some embodimentscontemplate means for aggregating location information 310 for aplurality of hosts 100, means for receiving event data 312, means forcomparing the aggregated location information 310 with the receivedevent data 312 to identify affected hosts 100, means for comparing theaffected hosts 100 with inventory 308 of VMs 235 to identify affectedVMs 235, and means for migrating one or more of the affected VMs 235from the affected hosts 100 to other hosts 100.

At least a portion of the functionality of the various elementsillustrated in the figures may be performed by other elements in thefigures, or an entity (e.g., processor, web service, server, applicationprogram, computing device, etc.) not shown in the figures.

In some embodiments, the operations illustrated in the figures may beimplemented as software instructions encoded on a computer readablemedium, in hardware programmed or designed to perform the operations, orboth. For example, aspects of the disclosure may be implemented as asystem on a chip or other circuitry including a plurality ofinterconnected, electrically conductive elements.

The order of execution or performance of the operations in embodimentsof the disclosure illustrated and described herein is not essential,unless otherwise specified. That is, the operations may be performed inany order, unless otherwise specified, and embodiments of the disclosuremay include additional or fewer operations than those disclosed herein.For example, it is contemplated that executing or performing aparticular operation before, contemporaneously with, or after anotheroperation is within the scope of aspects of the disclosure.

When introducing elements of aspects of the disclosure or theembodiments thereof, the articles “a,” “an,” “the,” and “said” areintended to mean that there are one or more of the elements. The terms“comprising,” “including,” and “having” are intended to be inclusive andmean that there may be additional elements other than the listedelements. The term “exemplary” is intended to mean “an example of.”

Having described aspects of the disclosure in detail, it will beapparent that modifications and variations are possible withoutdeparting from the scope of aspects of the disclosure as defined in theappended claims. As various changes could be made in the aboveconstructions, products, and methods without departing from the scope ofaspects of the disclosure, it is intended that all matter contained inthe above description and shown in the accompanying drawings shall beinterpreted as illustrative and not in a limiting sense.

1-20. (canceled)
 21. A system for relocating virtual machines (VMs) inanticipation of adverse events, said system comprising: a memory areaassociated with a computing device, said memory area storing aninventory of VMs in a virtualized datacenter; and a processor programmedto: aggregate location information for a plurality of hosts in thevirtualized datacenter, the hosts executing a plurality of the VMs, thelocation information associated with a plurality of racks in which thehosts are installed; receive event data comprising a description ofpotential adverse events; compare the aggregated location informationwith the received event data to identify a first host anticipated to beaffected by the potential adverse events; identify a second host that isanticipated to be not affected by the potential adverse events; comparethe identified first host anticipated to be affected by the potentialadverse events with the inventory of VMs stored in the memory area toidentify VMs anticipated to be affected by the potential adverse events;notify the identified second host of an impending migration of theidentified VMs; migrate one or more VMs of the identified VMsanticipated to be affected by the potential adverse events from theidentified first host to the identified second host; and obtain updatedlocation information from the one or more VMs migrated to the identifiedsecond host.
 22. The system of claim 21, wherein the processor isfurther programmed to prioritize one VM of the one or more VMs formigration from the first host to the second host based on a servicelevel agreement with a user.
 23. The system of claim 21, wherein theprocessor is programmed to receive event data by receiving at least oneof a weather forecast, an upcoming scheduled maintenance event, or ascheduled test event.
 24. The system of claim 21, wherein the processoris programmed to confirm successful migration of the one or more VMsmigrated to the identified second host upon receiving the updatedlocation information.
 25. The system of claim 21, wherein the processoris further programmed to power down other VMs anticipated to be affectedby the adverse event after migrating the other VMs to the other hosts.26. The system of claim 21, wherein the inventory stored in the memoryarea comprises cloud zones each storing one or more of the VMs.
 27. Thesystem of claim 26, wherein the event data adversely affects a first oneof the cloud zones, and wherein the processor is programmed to migratethe one or more of the VMs anticipated to be affected from the first oneof the cloud zones to a second one of the cloud zones.
 28. A method forrelocating virtual machines (VMs) in anticipation of adverse events,comprising: aggregating location information for a plurality of hosts inthe virtualized datacenter, the hosts executing a plurality of the VMs,the location information associated with a plurality of racks in whichthe hosts are installed; receiving event data comprising a descriptionof potential adverse events; comparing the aggregated locationinformation with the received event data to identify a first hostanticipated to be affected by the potential adverse events; identifyinga second host that is anticipated to be not affected by the potentialadverse events; comparing the identified first host anticipated to beaffected by the potential adverse events with the inventory of VMsstored in the memory area to identify VMs anticipated to be affected bythe potential adverse events; notifying the identified second host of animpending migration of the identified VMs; migrating one or more VMs ofthe identified VMs anticipated to be affected by the potential adverseevents from the identified first host to the identified second host; andobtaining updated location information from the one or more VMs migratedto the identified second host.
 29. The method of claim 28, furthercomprising prioritizing one VM of the one or more VMs for migration fromthe first host to the second host based on a service level agreementwith a user.
 30. The method of claim 28, further comprising receivingevent data by receiving at least one of a weather forecast, an upcomingscheduled maintenance event, or a scheduled test event.
 31. The methodof claim 28, wherein the processor is programmed to confirm successfulmigration of the one or more VMs migrated to the identified second hostupon receiving the updated location information.
 32. The method of claim28, further comprising powering down other VMs anticipated to beaffected by the adverse event after migrating the other VMs to the otherhosts.
 33. The method of claim 28, further comprising powering downother VMs anticipated to be affected by the adverse event aftermigrating the other VMs to the other hosts.
 34. The method of claim 33,wherein the event data adversely affects a first one of the cloud zones,and wherein the processor is programmed to migrate the one or more ofthe VMs anticipated to be affected from the first one of the cloud zonesto a second one of the cloud zones.
 35. A non-transitorycomputer-readable storage medium including computer-executableinstructions that, when executed, cause at least one processor toprotect virtual machines (VMs) in anticipation of adverse eventsaffecting a virtualized datacenter by causing the at least one processorto at least: aggregate location information for a plurality of hosts inthe virtualized datacenter, the hosts executing a plurality of the VMs,the location information associated with a plurality of racks in whichthe hosts are installed; receive event data comprising a description ofpotential adverse events; compare the aggregated location informationwith the received event data to identify a first host anticipated to beaffected by the potential adverse events; identify a second host that isanticipated to be not affected by the potential adverse events; comparethe identified first host anticipated to be affected by the potentialadverse events with the inventory of VMs stored in the memory area toidentify VMs anticipated to be affected by the potential adverse events;notify the identified second host of an impending migration of theidentified VMs; migrate one or more VMs of the identified VMsanticipated to be affected by the potential adverse events from theidentified first host to the identified second host; and obtain updatedlocation information from the one or more VMs migrated to the identifiedsecond host.
 36. The non-transitory computer storage medium of claim 35,wherein migrating the at least one VM anticipated to be affectedcomprises at least one of moving, replicating, or cloning the at leastone VM anticipated to be affected in anticipation of the future adverseevent.
 37. The non-transitory computer storage medium of claim 35,wherein the at least one processor receives event data by receiving atleast one of a weather forecast, an upcoming scheduled maintenanceevent, or a scheduled test event.
 38. The non-transitory computerstorage medium of claim 35, wherein the at least one processor confirmssuccessful migration of the one or more VMs migrated to the identifiedsecond host upon receiving the updated location information.
 39. Thenon-transitory computer storage medium of claim 35, wherein the at leastone processor powers down other VMs anticipated to be affected by theadverse event after migrating the other VMs to the other host.
 40. Thenon-transitory computer storage medium of claim 35, wherein theinventory stored in the memory area comprises cloud zones each storingone or more of the VMs.